home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
comm
/
hzcomm31.zip
/
FOSSIL.DOC
< prev
next >
Wrap
Text File
|
1987-03-07
|
20KB
|
546 lines
Fundamentals of FOSSIL implementation and use
Draft Version 3 March 7, 1987
Vincent E. Perriello, VEP Software
IFNA Address: Network 141 Node 491 (141/491)
Usenet address: ...decvax!envore!vaxine!spark!141!491!Vince_Perriello
Copyright (C) 1987, VEP Software, Naugatuck, CT 06770. All rights reserved.
This document may be freely used or copied by anyone interested in the data
contained herein. No fees may be charged for distribution of this document.
You will be held accountable for all such charges, and expected to either
reimburse those persons or organizations so charged, or to make a donation
in the exact amount of those fees to the International FidoNet Association,
to assist them in their efforts to advance the technology of personal
computer telecommunications.
Fundamentals of FOSSIL implementation and use Page 1
A. Objectives of this document
This document is directed at implementors or intellectuals. It is meant
for use in implementing applications that can use FOSSIL drivers, or for
details needed to implement a new FOSSIL. As such it won't always go out
of its way to explain itself to the neophyte.
This document will have served its purpose to you if you are able to use
the data contained within to perform either of the above tasks. If you
feel that necessary data has been omitted please contact Vince Perriello
at the above listed address so that the appropriate changes can be made.
B. Historical perspective
For those people who were not lucky enough to have an IBM PC or a system
nearly completely compatible, the world has not been very friendly. With
his implementation of the Generic Fido(tm) driver, Tom Jennings made it
possible for systems that had nothing in common with an IBM PC except an
808x-class processor, and the ability to run MS-DOS Version 2 and above,
to run his Fido(tm) software. That was a lot to ask, and a lot of people
thought it was enough.
But not everyone. While Thom Henderson was debugging Version 4.0 of his
SEAdog(tm) mail package, an "extended" Generic driver was designed (in
cooperation with Bob Hartman) as a quick kludge to help him get past a
problem with certain UART chips.The new hook was quickly pounced upon by
Vince Perriello, who, with almost DAILY prodding (ouch! it still hurts)
by Ken Kaplan,had been working with Henderson to get DEC Rainbow support
into SEAdog. Vince then coded a driver to use this hook and - Voila! -
SEAdog 4.0 started working like a champ on the Rainbow.
Then something WONDERFUL happened. Wynn Wagner started having a bad time
getting the Greenleaf(tm) Communication Libraries to work in exactly the
way he wanted them to. Enter Bob Hartman. Having already enjoyed success
in the effort with Thom Henderson, he suggested to Wynn that with a very
few extensions, the driver that SEAdog(tm) 4.0 liked could drive Opus as
well. Then Vince called Wynn, Wynn called Bob, Bob called Vince, and the
FOSSIL driver came into existence.
FOSSIL, by the way, is an acronym that Vince dreamed up. It took a while
for everyone to stomach it,but it now seems to be loved by all. It is an
acronym for "Fido/Opus/SEAdog Standard Interface Layer". And the concept
is catching on. Henk Wevers is reportedly coding a terminal program in
Turbo Pascal that uses FOSSIL services to do all the work. This should
mean that the result will play elsewhere. And there are already FOSSIL
implementations for the Tandy 2000, Sanyo 555, Z100 and others, so the
potential of a properly coded FOSSIL application is very great.
Fundamentals of FOSSIL implementation and use Page 2
C. Basic principles of a FOSSIL driver
1) Interrupt 14H.
The one basic rule that the driver depends upon, is the ability for ANY
target machine to allow the vector for INT 14H (absolute locations 50 to
53 in segment 0) to be "stolen" by the driver. In a system where the INT
14H vector is used already, it must be possible to replace the "builtin"
functionality with that of a FOSSIL, when an application that wants the
use of a FOSSIL is to be run on the target machine.
2) How to install a FOSSIL driver in a system
There's no hard and fast way to do this. The FOSSIL might be implemented
as part of a device driver (like Ray Gwinn's X00.SYS) and therefore gets
loaded using a line in CONFIG.SYS at bootup time. It might be done as a
TSR (terminate and stay resident) program, in which event you install it
by running the program (DECCOMM by Vince Perriello and Opus!Comm by Bob
Hartman work this way, for example).
3) How an application can detect the presence of a FOSSIL
The driver has a "signature" that can be used to determine whether it is
present in memory. At offset 6 in the INT 14H service routine is a word,
1954 hex, followed by a byte that specifies the maximum function number
supported by the driver. This is to make it possible to determine when a
driver is present and what level of functionality it provides. Also, the
Init call (see below) returns a 1954 Hex in AX. SEAdog(tm) looks at the
signature and Opus just goes for the Init. Fido doesn't do either.
4) How to call a FOSSIL function
The FOSSIL driver is entered by issuing a software Interrupt 14 Hex from
the application program. The code corresponding to the desired function
should be in 8-bit register AH. For calls that relate to communications,
the port number will be passed from the application in register DX. When
DX contains a zero (0) it signifies use of COM1, or whatever the "first"
serial port on your machine is called. A one (1) in DX points the driver
at COM2, and so on.
Fundamentals of FOSSIL implementation and use Page 3
D. Functions currently defined for FOSSILs
AH = 0 Set baud rate
Input: AL = baud rate code
DX = port number
This works the same as the equivalent IBM PC BIOS call, except that it
ONLY selects a baud rate. This is passed in the high order 3 bits of AL
as follows:
000 = 110 baud
001 = 150 ''
010 = 300 ''
011 = 600 ''
100 = 1200 ''
101 = 2400 ''
110 = 4800 ''
111 = 9600 ''
The low order 3 bits can be implemented or not by the FOSSIL, but in all
cases, if the low order bits of AL are 00011, the result should be that
the communications device should be set to eight data bits, one stop bit
and no parity. This setting is a MINIMUM REQUIREMENT of Fido, Opus and
SEAdog.
AH = 1 Transmit character
Input: AL = character
DX = port number
Output: AX contains status bits (see function 3)
AL contains the character to be sent. If there is room in the transmit
buffer the return will be immediate, otherwise it will wait until there
is room to store the character in the transmit buffer. On return, AX is
set as in a status request (see function 3).
AH = 2 Receive a character
Input: DX = port number
Output: AL = input character
If there is a character available in the receive buffer, returns with
the next character in AL. It will wait until a character is received if
none is available.
Fundamentals of FOSSIL implementation and use Page 4
AH = 3 Request status
Input: DX = port number
Output: AX = status bit mask (see below)
Returns with the line and modem status in AX. Status bits returned are:
In AH:
Bit 0 = RDA - input data is available in buffer
Bit 5 = THRE - room is available in output buffer
Bit 6 = TSRE - output bu